User interface for email inbox to call attention differently to different classes of email

ABSTRACT

A user interface for email users which calls attention to one or more categories of emails in different ways. In some species, at least three categories are used: branded senders with Trumarks; white list buddies; and fraudulent emails which are either not from the domain they purport to be from or in which the content was tampered. The preferred embodiment authenticates emails from branded senders and displays them with the sender&#39;s Truemark. Branded sender emails have their Truemarks displayed in the sender column of a list view in the preferred embodiment. In a preferred embodiment, white list senders have either an icon or other graphic or photo they choose displayed to the left or right of the sender column with their name in the sender column. In a preferred embodiment, fraudulent emails have a fraud icon displayed to the left or right of the sender column with a warning in the sender column. Antiphishing processing is also disclosed.

CLAIM OF PRIORITY

This application is a Continuation of U.S. application Ser. No.11/072,608 filed Mar. 3, 2005, which is incorporated herein byreference.

BACKGROUND OF THE INVENTION

With the increasing use of email for communication between friends andbetween companies and their prospective and existing customers, certainproblems have arisen. First and foremost is the problem of too muchemail especially from companies and other senders from whom therecipient does not particularly want to receive email. Because thevolume of email is growing, recipients tend to become oblivious to emailand ignore it except if it is from a friend or a client or somebody therecipient knows and wants to hear from. As a result, recipients ofunwanted email may delete important marketing or recall or othermessages from companies that arrive along with many other unwantedmessages.

Companies need a way to draw attention to their email so as to segregateit from other email thereby providing a better chance that their emailswill be received and read by users who are bombarded with unwantedemails from many senders.

Companies also want a way to reassure users that when a user receives anemail from the company, that the email is authentic and from thatcompany and not somebody trying to pass themselves off as that companyas a “phisher”. Phishing is a new development in the email world andinvolves unscrupulous individuals conning email users and browser usersinto believing they are communicating with an entity they want tocommunicate with when they are actually communicating with somebody theydo not want to communicate with. This can severely damage the reputationof a company, so any methodology by which legitimate companies canprotect their customers from phishers and communicate this fact to theircustomers and email recipients would be welcome addition to themarketing efforts of these companies.

Email recipients are especially interested in emails from their friends,clients, business associates and other persons with whom they want tocommunicate. It is important to these users that such emails be broughtto their attention so as to stand out in their inboxes from all theother emails they receive.

Finally, email recipients have an interest in protecting themselves fromphishing attacks. It is useful to email recipients to have emails thathave been confirmed to be fraudulent brought to their attention suchthat they stand out in the user's inbox from all the other user'semails.

A recent example involving Microsoft highlights the gravity of thisproblem. This story was published in the Feb. 14, 2005 issue of Newsweekat page 12. An MSN user received an email indicating there was somethingwrong with her account and she was directed to go a URL provided in theemail and re-enter her credit card number. At that URL, an officiallooking web page purporting to be hosted by Microsoft Network appeared,but it was a fake. The user was suspicious and referred the email to herson-in-law who worked for Microsoft. Microsoft launched an investigationto find out who was behind the fake website. Microsoft has a former U.S.Marshal as its lead cyberferret. Beginning in October 2003, Microsoftstarted an investigation filing suit against numerous John Does so itcould use subpoena power in it attempt to untangle the convoluted trailof the email and the phony web page. The email path dead ended at an ISPin India, so the investigation turned its focus to the owner of the fakeweb page. Every web page has a URL which is traceable to the servicethat hosts it. But these URLs can lead to other addresses assigned byother ISPs or co-location services. With each round, a subpoena had tobe served on the hosting ISP to find out who was paying for the service.The first round led to a company in San Francisco. The second round ledto another hosting service in San Fransciso. Round three led to a free“re-direction service” in Austria. There the trail would have endedbecause the subpoena power of the U.S. courts does not extend beyondU.S. borders. However, luckily, the Austrian owner of the re-directionservice hates phishers, and voluntarily provided the information. Thisinformation led to yet another internet address owned by Quest. Asubpoena of Quest led to Microsoft itself: an address assigned to aMicrosoft user who was a 69 year old man living in Davenport, Iowa. Theman had a 21 year old grandson, Harris, who lived in his house and was acomputer geek but who worked for Blockbuster. Microsoft then went to theFBI which searched the house in 2004 and siezed Harris' three computers.Microsoft then sued Harris who did not respond. Microsoft obtained athree million dollar default judgment. Good luck collecting on that. Thereal damage to Microsoft was in the possible losses to its customersfrom successful phishing attacks and the large amount of money and timeconsumed in the investigation.

Therefore, a need has arisen for a user interface and method ofoperating a computer to provide a protected email space where customersof the service can send emails and have their recipients free of fearthat the emails are from phishers and wherein the emails are set apartfrom other emails in some distinctive way. Preferably, the needed systemwill provide an email inbox which brings to the attention of the user indifferent ways emails which are known to be from particular companies,emails which are from friends, clients, etc. on a user's white list andemails which are known to be fraudulent.

SUMMARY OF THE INVENTION

The teachings of the technology claimed herein contemplate a userinterface for displaying a list view of emails and calling attention inany way to certain emails in the list view which are in certaincategories. The claims call for apparatus and processes and computerreadable medium carrying instructions which control a computer to createuser interface displays which call attention to the one or morecategories of emails differently. In the preferred embodiment, fourdifferent categories of email exist, each of which is called attentionto differently. In other alternative embodiments, single categories ofemail are called attention to set them apart from all other emails. Forexample, branded emails from subscribers who have passed a due diligenceinquiry and proven that they have a registered trademark will have theiremails set apart from all other emails by a display of their corporatelogo or trademark in the sender column of a list view of emails viewedusing a web browser or email client.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of the hardware and software environment in which aTruemark based embodiment is practiced.

FIG. 2 is a screen shot of an email client inbox which is displayed whenthe computer is being operated in accordance with the teachings of oneembodiment.

FIG. 3 is a block diagram of a typical system in which the genus ofprocesses using graphics such as buddy lists to call attention to emailsoccurs.

FIG. 4 is a diagram of the first species in the antiphishing genus wherethe authentication/integrity check and sender policy check are done atdifferent locations.

FIG. 5 is a diagram of the environment in which another species in theantiphishing genus is performed where the authentication/integrity checkand sender policy check are done at the mail transfer agent.

FIG. 6 is a diagram of the environment in which another species in theantiphishing genus is performed where the authentication/integrity checkand sender policy check are done at the mail user agent.

FIG. 7 is a block diagram of a hardware architecture in which certainembodiments are practiced.

FIG. 8 is one possible software architecture which shows the varioussoftware programs and physical layer interface to the internet whichforms one possible environment in which certain embodiments are carriedout.

FIG. 9, comprised of FIGS. 9A through 9C, is a flow diagram of oneembodiment of how one species of the value added process cooperates witha web browser, a web mail server and the assignee server and the clientcomputer TCPllP stack to generate user interface displays in accordancewith a class of embodiments using stemps.

FIG. 10, comprised of FIGS. 10A through 10C, is a flow diagram of howone species of a value added process cooperates with an email client ona client computer, an email server and the assignee server and theclient computer TCP/IP stack to generate user interface displays inaccordance with another class of embodiments.

FIG. 11 is a screenshot of the preferred form of user interface displaythat occurs when an event called the branded mouseover occurs in someembodiments.

FIG. 12 is a screen shot showing one embodiment of a buddy mouseoverpopup display which occurs when a user passes the mouse cursor over awhite list email currently being displayed.

FIG. 13 is an a process flow diagram showing the preferred class ofprocesses regarding how emails are authenticated and categorized anddisplayed with Truemark branding.

FIG. 14 is a protocol flow diagram of one embodiment of a processimplemented by uniquely programmed computers to do the authenticationand integrity checking embodiments.

FIG. 15 is a flow diagram of another embodiment for doing authenticationand integrity checking.

FIG. 16 is a table that shows one embodiment of what is displayed foreach different authentication result for each different category inembodiments where there are five categories: Truemark customer with FUAPset to true; Truemark customer with FUAP set to false; white list buddy;non member buddy; and non member.

FIG. 17 is a flowchart showing the preferred process for displayingexternal sender data.

FIG. 18 is a flowchart of the preferred process of presenting anunsubscribe interface.

FIG. 19 is a flowchart of a process for presenting frequency metrics.

FIG. 20 is a flowchart of a process for detecting fraudulent emails anddisplaying them with a fraud indication.

FIG. 21 is a flow diagram of a preferred embodiment carried out by avalue added process to authenticate and integrity check incoming emailsand display Truemarks.

DETAILED DESCRIPTION OF THE PREFERRED AND ALTERNATIVE EMBODIMENTS

One important aspect of at least some embodiments of the inventioncontemplates any process implemented with any hardware and any softwareto increase the trust of email communications. The genus of processesfor increasing the trust of email communications comprises the followingsteps:

-   -   verifying an association between a sender and certain        trademarks, service marks, copyrighted data, sounds, smells,        jingles, and/or licensed data and/or any other humanly        perceptible computer behavior hereafter known as Truemarks;    -   receiving an email from said sender, wherein said receiver's        domain name may or may not be the same as sender's domain name;    -   checking said received email for authentication and/or        integrity;    -   using a mail user agent to control a device capable of        displaying email to display at least some information about said        received email and use a Truemark somewhere in the display of        information about said authenticated and integrity checked email        to call attention to said email.

Any species that performs at least these four steps will increase thetrust of email and is within this particular genus of processes. Animportant part of this genus of processes is verifying that an emailcame from the entity which it purports to be from (referred to herein asauthentication) and an integrity check. This authentication andintegrity checking can be done anywhere on the receiving side of theemail transaction. For example, it can be done at an incoming mailtransfer agent, an incoming web mail server, by an email thick clientprocess. Either sender authentication or domain authentication willsuffice. Sender authentication means that the email is in fact from thesender who it purports to be from. Domain authentication means thatverification that the email came from the domain it purports to be fromhas occurred. An integrity check means that the email has been checkedto ensure that it has not been altered.

A mail user agent is any combination of hardware and software thatcontrols a device for displaying emails so as to call attention to oneor more categories of emails using any humanly perceptible means. A mailuser agent can be one or more software processes running on a server, aclient computer, a cell phone, any wireless device that can retrieve ordisplay emails, and it can call attention to any one or more categoriesof emails in any one or more of the ways described herein or using anyother humanly perceptible mechanism not described herein.

Step one of this genus of processes involves verification theassociation between the sender and the Truemark. This is a manualprocess in the form of a due diligence investigation. The preferredmethod of carrying out this process is as follows. All corporate logo orbranded senders must go through a manual due diligence process ofverification before they are allowed to have their registered trademarksdisplayed as Truemarks with their emails. Generally, in this process, arepresentative of the assignee visits the branded sender and verifiesthe company is who it says it is, and that the company has the exclusiveright to use the proposed Truemark, as proven by a registration of theTruemark at the United States Patent and Trademark Office. The brandedsender will also have to prove that the person requesting the brandedsender status and access to the protected email space is authorized bythe company to make such a request. Foreign branded senders must, in thepreferred embodiment, register their proposed Truemarks at the UnitedStates Patent and Trademark Office to achieve branded sender status. Inalternative embodiments, the requirement for registration of a mark canbe relaxed.

In some embodiments, branded senders may have as their Truemarksunregistered corporate logos or other images or designs displayed in thesender column and the requirement for registration as a trademark may berelaxed.

If everything checks out properly in this due diligence process, theTruemark will be authorized and the corporate client will be allowed toupload their Truemark to a Truemark server 3 in FIG. 1. Truemarks may bestored on a server but they could also be published.

Step 2 of the genus is to receive the email. This is a conventionalprocess and will not be further discussed.

Step 3 of the genus is to check each received email for authenticationand/or integrity. Either or both processes will suffice. Any knownprocess for verifying the email came from the sender or domain itpurports to be from and/or has not been tampered with will suffice topractice this class of embodiments. The preferred embodiment uses theDomain Keys technology defined in the Yahoo public specification to doboth authentication and integrity checking.

Step 4 of the genus is to use a mail user agent to call attention to anyemail which passed the integrity and/or authentication checks of step 3by displaying or otherwise presenting in some humanly perceptible form aTruemark associated with the sender along with at least some informationpertaining to the email checked in step 3.

FIG. 1 is a block diagram of the preferred hardware and softwareenvironment in which the preferred species within the above describedgenus of processes is carried out. Sender domain name service 1 is aprocess running on a server which can return a public key for thatdomain. Mail user agent 2 is a email recipient's computer running one ormore processes that call attention to emails in one or more ofpredetermined categories using any humanly perceptible user interfacemechanism. Truemark server 3 is a server which stores Truemarks. Atypical email transaction involves an outgoing mail server 4 digitallysigns an email received from a sender's client computer using a senderdomain's private key. The signed email is sent to the mail user agent 2through the internet 5. The mail user agent receives the email andperforms authentication and integrity checking. It does this byrequesting the sender domain's public key from sender domain nameservice 1 and verifying the digital signature in accordance with theDomain Keys public specification published by Yahoo. If the email passesthe authentication and integrity checks, a Truemark associated with thesender is retrieved from the Truemark server 3 and the mail user agentcontrols the recipient's computer to display at least some informationabout the email and displays a truemark. The preferred way of displayinga truemark is to display the Truemark in place of the sender column, asshown at 12 and 21 in FIG. 2. FIG. 2 is a screen shot of an email clientinbox which is displayed when the computer is being operated inaccordance one class of embodiments.

Various species within this genus: 1) display the information about theemail as a summary line in an email list view; 2) replacing a column ina list view summary line representation of the received email with aTruemark; 3) adding an additional column in a list view of emails inwhich a Truemark is displayed for any email on the list which has passedauthentication and integrity checking; 4) adding to a column in a listview of emails received a Truemark for any email which has passedauthentication and integrity checking; 5) display information about theemail in the form of displaying the main body and the header of theemail; 6) using two or more processes to implement the mail user agent;7) using the mail user agent to check the authentication and/orintegrity of the received email; and 8) using the incoming mail serverto do the authentication and/or integrity checking of the incomingemail.

Genus of Buddy Icon (or Other Graphic Display) Processes

The following steps define a genus of processes which display graphicssuch as custom buddy icons associated with a sender along with at leastsome information about an email from said sender. The graphic caninclude photographs, icons, drawings, scanned images, etc. The genusrequires that all species within it carry out the following two steps:

-   -   receiving an email from a sender whose domain can be different        than the domain of the receiver;    -   using a mail user agent to control a device capable of        displaying email to display at least some information about said        received email and to display a graphic associated with said        sender somewhere in the display of information about said email        to call attention to said email.

The first step in this process is receiving an email. This is aconventional process and can occur in a web mail server or a recipientcomputer. The domain of the sender can be different than the domain ofthe receiver, and this distinguishes any prior art where buddy icons orother graphics are displayed with received emails.

The second step is using a mail user agent to control a computer todisplay information about the email along with the graphic. This can bedone by processing at a web mail server or at a recipient device capableof displaying emails.

FIG. 3 is a block diagram of the environment in which one embodiment iscarried out where the graphic is retrieved by a mail user agent from agraphic server. In this species, mail user agent 2 controls its hostcomputer to receive an email from an outgoing mail server 5. Inresponse, the mail user agent 2 retrieve the sender's graphic from asender graphic server 6. In alternative embodiments of this species, thegraphic may be stored in the header of the email or in an emailattachment. In another alternative embodiment of this species, thegraphic is stored in another server out on the internet, and thelocation of the graphic is pointed to in information supplied in theemail, or the graphic is pointed to in information obtained by the mailuser agent. In another alternative embodiment, the graphic is retrievedfrom local storage.

The processing at the web mail server in the preferred embodiment wouldinclude exporting data regarding the email to a device capable ofdisplaying email (the recipient device) which established a session withsaid web mail server and exporting data which includes the graphic or apointer to where the graphic may be obtained by the recipient device.The exported data would cause a mail user agent at the recipient deviceto display information about the email along with a graphic.

An example of one species within this embodiment is a display which step2 creates in a device capable of displaying emails a display of a listof emails with buddy icons displayed next to the sender column, as shownat 30, 32 and 34 in FIG. 2. Other alternative embodiments within thisgenus would be: 1) to use said mail user agent to retrieve said graphicfrom said header of said email; 2) to use said mail user agent toretrieve said graphic from an attachment to the main body of said email;3) using said mail user agent to retrieve the graphic from a contactmanager which stores information associated with each sender; 4) usingtwo or more processes to carry out the functionality of the mail useragent.

Value Added Process for Web Mail

Currently, web mail services exist, but the functionality of limited tothe services the web mail server provides. It is useful for a clientcomputer or other device which is capable emails such as a cell phone orPDA to be able to add its own functionality to the web mail service.Examples of additional functionality that would be useful include usinga valued added process on the recipient device that can analyze emailsto recipient and determine automatically which emails are spam and takeappropriate action. Another example of a value added process isauthentication and integrity checking and displaying a Truemarkassociated with a sender of any email which passes authentication andintegrity checking. Another example is display of a graphic such as abuddy icon with any email which has been sent by a sender who hasdesignated a graphic to be displayed with said sender's email. The stepsof the value added genus process are:

-   -   1) detecting an event in a device capable of displaying emails        indicating a browser has or is attempting to contact a web mail        service;    -   2) intercepting events returned to said browser by said web mail        service;    -   3) controlling said device capable of displaying emails in an        email account to either: 1) implement any value added service        associated with an email; 2) present as a display on said device        a method to access value added services pertaining to said        emails being displayed; 3) incorporate data into a display of        said emails which would not otherwise be there.

In this genus, a value added process executing on a device capable ofdisplaying emails monitors events published by a browser and detects thefact that the browser of said device has established or is attempting toestablish contact with a web mail service. When such contact isestablished, the user of the device typically logs into the web mailservice and requests a list of new emails. The web mail service hostserver then looks up the user account and exports data to the devicewhich causes the device to display a list view of the recipient'semails. This data is intercepted or monitored by the value addedprocess. The final step involves controlling the device to either: 1)implement any value added service pertaining to emails being displayedwhich would not otherwise be provided by the web mail server (such asauthenticating and integrity checking, or spam detection, or spamdetection and moving email classified as spam into a spam folder, ordeleting an email classified as spam stored on a web mail server so thatthe spam mail never gets displayed on the client device); 2) present amethod to access value added services pertaining to said emails beingdisplayed which would not otherwise be there (such as a link to triggeran authentication and integrity check, or a button to mark an email asspam); 3) incorporate data into a display of said emails which would nototherwise be there (such as presenting a Truemark for emails which havepassed an authentication and integrity check, or a mark indicating thatan email has been classified as spam). A flow diagram for this processis presented as steps 82, 84, 86, 88 and 90 of FIG. 9A where step 90 isreplaced by any one of the three options described above for step 3 ofthe process.

The value added service that controls a client device to do spamdetection or spam deletion or detection of spam and moving it to a spamfolder can be implemented in any of the ways these function have beenimplemented in the prior art. Specific examples of prior art whichperforms some or all of these spam management functions are: manualselection of an email followed by receipt of a user command indicatingthe email is spam, using a black list of spam sender address or spamdomains (which can be built automatically from manual markings of emailas spam), using keywords such as Viagra to detect spam, using Bayesiananalysis, using voting algorithms where each client can mark an email asspam and the results for that type of email are calculated and used bythe rest of the community, using learning algorithms based on individualspam classification behaviors, etc. These are all ways of detectingwhether an email is spam.

Once an email is detected to be spam, the value added service can addnew functionality for spam management that is not already present in theweb mail service. For example, the value added service can interceptdata regarding the display of an email which has been found to be spamand modify that data to cause a spam graphic to be displayed next to thesummary line for that email in a list view. In an alternative species,the spam management service can send commands to the web mail servicepertaining to a particular email which has been detected to be spam inany of the ways above, said commands simulating button clicks or otheruser commands that a user of the web mail service would give to delete aparticular email or move an email to a spam folder. In an alternativeembodiment, the spam management service could intercept data from theweb mail service controlling the browser to display an email which hasbeen detected to be spam and modify that data such that the spam emailis not displayed.

A specific example of a species within this genus is the flowchart ofFIG. 21 (D5) where the value added service is an authentication andintegrity check followed by display of a Truemark for emails whichpassed authentication and integrity checking. Other examples of specieswithin this genus are: 1) implementing said value added service as abrowser plug-in which controls said device to display information aboutemails in accordance with data supplied by said web mail service alongwith calling attention to one or more categories of said emails in anyhumanly perceptible way; 2) implementing said value added service as aserver process for channeling browser calls to said web mail service; 3)implementing said value added service value added as a check email forauthentication and/or integrity of an email; 4) implementing said valueadded service by presenting a function which a user can invoke to markan email as fraudulent or as spam; 5) implementing said value addedservice as a service which automatically goes through a web mail emailinbox and creates a contact list generated from emails listed therein,said contact list being selectively displayable upon command from theuser.

Antiphishing Genus

A process to prevent con artists from sending emails purporting to befrom somebody else and asking for information that can be used for fraud(phishers) is very useful and adds to the trust of email. The genus ofsuch processes is defined by the following steps:

-   -   receiving an email from a sender using a mail user agent;    -   accessing said sender's fraud policy and checking said received        email against said fraud policy to determine if said email is        fraudulent; and    -   if said received email fails the requirements published as part        of said fraud policy which includes as a minimum requirement        that said received email pass authentication and integrity        checks, controlling a device capable of displaying emails to        display at least some information about said received email and        and provide information indicating said email is fraudulent.

This genus of processes can have the various steps done anywhere on thereceiving side of the email transaction. A typical email environmentincludes a mail transfer agent server (generally the incoming mailserver) coupled to a mail user agent. The antiphishing process can havevarious ones of its steps performed at any of these three computers.There are multiple embodiments to be described below. The second step ofaccessing a sender's fraud policy and checking the email against thefraud policy has a substep of first authenticating the email as beingfrom the sender it purports to be from and/or performing an integritycheck to ensure the email has not been tampered with. All sender fraudpolicies will include such an authentication and/or integrity check. Thefraud policy may also include other requirements such as all legitimateemails from the sender must come from a specific domain owned by thesender.

Referring to FIG. 4, there is shown a diagram of the first species inthe antiphishing genus where the authentication/integrity check andsender policy check are done at different locations. In this embodiment,the first step of receiving an email from a sender and the portion ofthe second step involving authentication and integrity checking areperformed at the mail transfer agent 400. The mail transfer agent theninserts an authentication header in the email which includes the resultof the authentication and/or integrity check and forwards the email to amail user agent 402. The mail user agent then access the sender's fraudpolicy from wherever it is stored and check the email against the fraudpolicy. The authentication header is used to determine if the emailpassed authentication and integrity checking, and then, if so, any otherrequirements of the fraud policy are checked against the email to ensureit complies with them. If the email does not satisfy all requirements ofthe fraud policy, the mail user agent controls a device capable ofdisplaying emails (a recipient client computer, cell phone, PDA etc.) todisplay some information about the email and to provide information thatthe email is fraudulent. This can be done in a number of different wayssuch as displaying a fraud icon next to the sender column of thefraudulent email, displaying a pop up box when a mouse cursor passesover the email which includes text indicating why the email failed thefraud policy, etc. In some embodiments, any email from a sender with nofraud policy will be marked as fraudulent.

Another species within this genus is illustrated in FIG. 5. In thisspecies, the mail transfer agent 400 does the authentication and/orintegrity check and also accesses the sender's fraud policy and checksthe received email against the fraud policy. A policy results header isthen added to the email before it is forwarded which includes resultdata indicating whether the email met all the requirements of the fraudpolicy. The mail user agent 402 then uses the policy results headercontents to control a device capable of displaying emails to displayinformation about the email and to provide information indicating theemail is fraudulent if that is what the data in the policy resultsheader indicates. Again, the way the information is provided that theemail is fraudulent can be several different ways.

Another species within this genus is illustrated in FIG. 6. In thisembodiment, the mail transfer agent does what mail transfer agents doand nothing more. In this embodiment, a mail user agent 402 receives theemail from the mail transfer agent and does the authentication and/orintegrity checking. The mail user agent then accesses the fraud policyand checks the email against that fraud policy. If the email fails tomeet the requirements of the fraud policy, the mail user agent controlsa device that is capable of displaying emails to display informationabout the email and provide information that it is fraudulent. This canbe done by a browser plug in executing on a recipient's client computer(or cell phone or PDA) which receives data from the mail transfer agentas a web mail server. The plug in does the authentication and/orintegrity checking and accessing of the sender fraud policy andcomparison of the email to the fraud policy. Then if the email fails,the plug in intercepts the data being sent to the operating system bythe browser and modifies it to display a fraud icon in or next to asummary line about the email in a list view or displays a popup when theemail is moused over that displays information about the emailindicating that it failed the fraud policy or why it failed the fraudpolicy.

In all these species, emails for which the sender has no fraud policyare either marked as fraudulent or are called attention to in some otherway to indicate to the user that the authentication and/or integrity ofthe email cannot be confirmed. This user interface mechanism can be anyhumanly perceptible mechanism such as coloring the summary line aboutthe email yellow or playing a sound when the email is moused over, etc.

Various Alternative Embodiment Species within the Teachings of theInvention

There are described below various species within the various inventiveclasses defined above. To the extent any of the descriptions belowconflict with the definitions and genus descriptions above, thedefinitions and genus descriptions given above control, and theconflicting definition or genus below is a species within one of theabove defined genus or an alternative genus.

First, with regard to Truemarks, in some embodiments emails can only bedisplayed with Truemarks which are known to come from a domain or senderwhich is known to be associated with a client who has satisfactorilyproven a right to exclusive use of a Truemark. In the some embodiments,a Truemark must be a registered trademark or service mark. In otherembodiments, it can be an unregistered corporate logo or other behaviorwhich a computer can carry out or be adapted to carry out and which canbe perceived by humans. In some species, Truemarks can be ways ofbringing attention to emails in various categories in various ways suchas: brands, logos, trademarks, music, sound marks, color marks, displaysof authenticity certificates, etc. This gives the client a protectedadvertising space in which to generate trust in its customers thatemails from this client actually come from this client.

Any hardware architecture and software structure which can cause tohappen this special “bringing attention” user interface to one or morecategories of emails will suffice. In some embodiments, multiplecategories of emails are called attention to by the user interface indifferent ways, and this can be done at the mail user agent or theincoming mail server which controls the displays on a device capable ofdisplaying emails. In some embodiments, the computer programmed to causethe special display (or any other means of calling attention to thedifferent categories of emails in different ways) can be a web mailserver such as the Yahoo or Comcast web mail server or an email clientsuch as Outlook or Outlook Express, or a conventional web browser oremail client coupled with another value added process such as a plug inwhich controls the computer to implement the novel user interface.

In some embodiments, this special user interface is coupled withbackground authentication processing to verify that each email notmarked with a fraud logo is from the domain it appears to be from andhas not been tampered with. In the some embodiments, the email space isprotected from phishers and others trying to pass themselves off as thebranded sender or trying to tamper with their messages. The visual spaceprovides an instant visual hierarchical view of emails in differentcategories in some embodiments through the use of different kinds oflogos displayed with each email in one of the categories to whichspecial attention is to be called. In some embodiments, the differentcategories are: a cross product of authentication and integrity (pass,fail, unable to verify) and reputation—branded sender with a Truemarkcustomer, buddy, non buddy member, non member. In some embodiments,Truemark customers have a “flag-unauthenticated-as-phishing” (FUAP)option. If that option is set, then all unauthenticated emails fromtheir domain will be presented as fraudulent by the value added servicethat implements this class of embodiments.

In some embodiments, a value added program implements a process tocooperate with the web browser or email client, a web mail server orother server operated by the assignee to modify the data being displayedso as to cause the special user interface display (or other ways ofcalling attention to the different category emails) that calls attentionto the different categories of emails.

In some embodiments, the computer which causes the special display is aweb mail server, and it is programmed to do the normal functions of aweb mail server to store emails of each customer and send to thatcustomer's computer display data which shows the customer which emailshe has received. However, in other embodiments it is also programmed toauthenticate the email. This can be done using Domain Keys technology orby cooperating with a server run by the assignee to authenticate emailsusing digital signatures or any other authentication technology. In someembodiments, web mail server also cooperates with a server controlled bythe assignee which may store buddy list graphics, Truemarks, personalinformation about registrants, authentication results, fraud policies,status of senders, etc. This cooperation is used in these embodimentstypically to determine the status of each email sender and use theauthentication results to modify the data being sent for display on theclient computer so as to cause the special display or other userinterface functions which call attention to emails from branded senders,white list senders and fraudulent emails in different ways. In someembodiments, emails directed to each user are categorized by the webmail server into different categories: branded sender, white list,fraudulent, all other. The web mail server in these embodiments thencontrols data sent to the client computer to display (or otherwise callattention to) the user's emails in each category in a different way.

In some embodiments, the emails which are in the categories that arecalled attention to in different ways have a verifiable piece such asthe identity of the sender, a verifiable digital signature or verifiablemetadata with one of the categories being emails which did not verifyproperly

In some embodiments, there are three classes of emails which are calledattention to in different ways: emails from branded senders; emails fromwhite list senders and emails which are known to be fraudulent. Adetermination that an email is fraudulent can be in any way known in theprior art. For example, in some embodiments, checks can be made todetermine if something has been tampered with such that a reconstructeddigital signature did not decrypt properly into the same hash that wasoriginally used to generate the digital signature transmitted with theemail.

In some embodiments, the user interface will not display an email unlessthe email has been authenticated. Authenticated, in some embodimentsmeans the identity of its sender has been verified or that nothing hasbeen tampered with since the email was created, or both. In otherembodiments, the ability to display metadata about the email ispresented as a tool to the user such as the mouseover embodimentsdescribed below. In some embodiments, the email is protected byincluding the header and the main body and any other parts that need tobe protected as inputs to a digital signature algorithm that hashesand/or encrypts all the parts and uses the result as a digitalsignature.

In some embodiments, creation of the digital signature can be done atthe sender computer or at an outgoing mail server of an internet serviceprovider (ISP). In other embodiments, authentication of an email can beperformed by the incoming mail server of an ISP or at the clientcomputer of the recipient of the email or by cooperation between theclient computer and a server run by the assignee or the incoming mailserver of the ISP. In various alternative embodiments, authentication isdone by any known process such as: 1) using the Domain Keys service; 2)by recreating the digital signature and comparing it to the digitalsignature in the email; 3) Identified internet mail (IIM), 4) bycryptographic processes being developed by the MASS group in theInternet Engineering Task Force (IETF); 5) by the procedures describedin a U.S. patent application entitled METHOD AND APPARATUS FORIMPLEMENTING A MICROPAYMENT SYSTEM TO CONTROL E-MAIL SPAM, filed Feb.12, 2004 and having Ser. No. 10/778,956, which is hereby incorporated byreference; 6) by SPF/SenderlD or S/MIME processing.

In some embodiments, the following process can be used to implement auser interface to call attention to various categories of emails:

-   -   receiving data pertaining to incoming emails addressed to a        recipient;    -   determining whether each said email is authentic in any way;    -   determining a category into which each email falls based upon        the sender of said email; and    -   generating data to cause a computer to call attention to each        email addressed to a recipient in a different way depending upon        into which category said email fell.

A genus of alternative embodiments pertaining solely to processes foroperating a computer to call attention to emails in different categoriesin different ways is defined by the following characteristics that allembodiments in the genus will share:

-   -   after a category in which said email's sender falls has been        determined, generating commands and/or data which cause a        computer to call attention to emails in each of a predetermined        number of categories in different ways; and    -   using said data to cause a computer to call attention to emails        in each of a predetermined number of different categories in        different ways.

The different ways can be: displaying different logos for each class;different colors; different scents or vibration patterns for each class;different behavior of the computer on mouse over of emails in differentcategories; associating emails with cost incurred by the sender orrecipient by quantifiable metrics; filtering or sorting of emails bycategory and by cost incurred to send them by any quantifiable metrics;or anything else which would give a user a sensory cue as to whichemails fall within which classes.

Referring to FIG. 2, there is shown a screen shot of the user interfacefor some embodiments in the form of an email inbox the way it isdisplayed in one embodiment when Yahoo!_web mail is used and when thecomputer is being operated in accordance with the teaching of the userinterface embodiments. The order of the emails in the inbox display isdetermined by the Yahoo web mail application running on the Yahooserver. But there is a process running invisibly in the background onthe client computer (the one the email user is sitting at when he or shedirects the client computer browser to the Yahoo web mail server's URL.This process interacts with the client computer web browser, the serverof the assignee of this patent application and the web mail server atwhich the user has an account to cause the display of FIG. 2. Any way inwhich the interactions occur to cause a display or other indicationwhich can be sensed by a human which brings to the attention of the userin some way the branded emails, the white list emails and the fraudulentemails will suffice to practice this class of embodiments. In otherwords, displayed logos or trademarks are not the only way attention canbe called to specific emails. Other embodiments are specific tunes,sounds, jingles, scents, vibration patterns etc. whenever an email in adisplayed list view is selected or moused over.

In some embodiments, there is a value added process running on a clientcomputer (50 in FIG. 7) that controls generation of a display on aclient computer of an inbox in which the user's emails are displayed(the display can also be of emails moved to trash or sent emails). Thisprocess or functionality will be called the value added process in someembodiments because it alters the display of the inbox (or causes someother user interface sensory event) to call attention to emails in thevarious categories described herein differently. The program thatimplements this process will be called the value added program in theseembodiments. In other embodiments, the value added process is executedon a web mail server (56 in FIG. 7) and cooperates with a web mailprogram to control the data that is sent by the web mail program to theclient computer so as to cause the web browser of the client computer tocontrol the client computer to display emails in various categoriesdifferently so as to call attention to them.

In an important alternative embodiment, the functionality of a valueadded program is integrated into a web mail application program executedon the web mail server such that the web mail application programimplements a process which includes the functionality of the value addedprocess so as to transmit data to the client computer's web browserwhich forces it to display a list of emails in so as to call attentionto emails in the various categories described herein differently. Thefunctionality of the value added process is incorporated into thefunctionality of an email client.

In some embodiments, there are four categories of emails which the userinterface displays in different manners so as to call attention to theemails in each category in a different way.

The first category of emails which this class of embodiments callsattention to for the user is email from a certified sender who hasauthorized a service to display the email with the Truemark of thatsender. Corporate branding is very important to marketing strategies ofmany corporations. For example, Federal Express does not want its emailsto be buried amidst hundreds of spam messages and other messagescluttering a user's inbox. Branded senders appreciate the branded emailspace which is protected from phishers and persons who may wish totamper with the branded senders emails all of which is provided by thevalue added process described herein. Most companies spend more money onmarketing than they do on research and development, so this protectedemail space where they can send messages to their customers cheaply is avery valuable tool to them.

In one embodiment, certified/branded senders who want their registeredtrademark (or other corporate logo) used have their Truemark displayedin the sender column 10. Examples of emails from certified/brandedsenders in FIG. 2 are shown at lines 12, 21, 26. In each case, aregistered trademark or Truemark is displayed in the sender column ofthe email as opposed to the name of the sender.

In another embodiment, the second category of emails that are displayedin a special way in the inbox (or any other list view) to draw attentionto them is emails from buddies or people on the recipient's white list.A white list is a list of senders from whom a recipient is happy toreceive mail. White list emails are displayed, in this embodiment, witha logo to the left of the sender column. However, in other embodiments,the logo for a white list sender could be placed in the sender columnand displayed in a different color or displayed to the right of thesender column and to the left of the subject column 28. Examples of thedisplays in this embodiment of white list emails are shown at lines 30,32, 34, 36, 38 and 40. In some embodiments, each white list sender canupload a logo, photograph, icon or other graphic (hereafter collectivelyreferred to as a graphic or sender logo) they wish to have displayedwith their emails. If they do not upload a sender logo, then a genericsender icon will be displayed for them. Examples of white list senderswho have uploaded custom sender logos for themselves are shown at lines30, 32 and 34. Examples of white list senders who have not uploadedcustom logos and who are using generic logos are shown at lines 36, 38and 40.

In some embodiments, the third category of emails that this class ofembodiments calls attention to to set them off from emails in all othercategories is known fraudulent emails such as emails from phishers,domain spoofs or emails which are suspected to be fraudulent such asemails from persons or addresses known to have sent fraudulent emails inthe past. Hereafter, known fraudulent emails and emails which aresuspected to be fraudulent will collectively be referred to asfraudulent emails.

Phishers are people who send emails and attempt to pass themselves offas somebody they are not. One way in which phishers are detected isdescribed in prior U.S. patent application entitled USER INTERFACE ANDANTI-PHISHING FUNCTIONS FOR AN ANTISPAM MICROPAYMENTS SYSTEM, Ser. No.10/935,260, filed Sep. 7, 2004, which is hereby incorporated byreference. Any way in which phishers and fraudulent emails are detectedor emails are classified as suspected fraud will suffice for purposes ofpracticing some embodiments. All that the user interface embodimentsrequires is that once an email has been determined to be fraudulent,that it be set off or called attention to in any manner from otheremails in other categories. This can be done in any way. In FIG. 2, aknown fraudulent email is shown at line 42 and is set off by the displayof a fraud icon to the left of the sender column. In other embodiments,a distinctive color or font is used with a strikethrough at least thesubject line and with a special fraud alert logo shown to the left ofthe sender column. A pop up box with a stop sign or some other warningin it which is displayed on mouse over could also be used or a soundmark on mouse over could also be used. Any one or more of thesetechniques or any of the alternative techniques described below can beused to call attention to the fraudulent email.

Alternative User Interface Attention Grabbing Mechanisms

In some embodiments described so far, logos placed in specific positionshave been used to set each of the first three different categories apartfrom the other categories. Visual logos are preferred because they arewell known and easy to implement. However, in some embodiments,different colors for each category could be used where multiplecategories are called attention to or Truemarks are involved. In otherembodiments, different sound marks could be played whenever an email isadded to the inbox depending upon the category of the email or wheneverthe user “mouses over” the email.

The process of passing a cursor over some part of an email will bereferred to herein as a “mouse over”. With respect to sounddiscrimination, branded senders could have a unique sound mark which isdifferent for each branded sender, a white list sender could have asecond generic sound mark or a unique sound mark and known fraudulentemails could have a third sound mark. In some embodiments, these soundmarks could be played either when the email arrives or when the userpasses the cursor over some designated part or any part of the email'sdisplay in the inbox. In some embodiments, different scents or differentvibration patterns could be emitted from the computer when an email isadded to the inbox or “moused over”, each category having a differentscent or vibration pattern.

Various embodiments use positioning of a corporate logo, white list logoand fraudulent email logos as shown in FIG. 2 because it give animmediate discriminatory picture based upon placement. Other embodimentsmay use different types of logos in the sender column with a mouse overpop up that identifies the sender with more specificity. In someembodiments, if the cursor or insertion point is located over an emailbeing displayed, information about the identity of the sender isdisplayed. That information may be stored locally or may be fetched froma server 58 (which can be a single server or a distributed serverfunction) by the value added process sending the sender's email addressor ID to the server 58 in FIG. 7 with a request to send back identityinformation from a sender profile stored by said server 58. This server58 can be any trusted server operated by anybody which cooperates withthe other processes described herein to perform the functions describedherein (hereafter referred to as the assignee server although theassignee of this patent application may not actually own or operate thisserver).

In some embodiments, when the cursor is over an email, the value addedprocess uses the email address (or identity) of the sender to look upinformation about the sender including the sender's identity. Thisinformation is included in data transmitted to a web browser on theclient computer to cause the client computer to display a pop up box orspecial window in which the identity of the sender of the email isdisplayed.

In some embodiments, the value added process paints an inbox displayshown in FIG. 2 or any of the other alternative embodiments is a plug inwhich is downloaded from the assignee's server to the client computer.In some alternative embodiments, the functionality of the value addedprocess 74 is implemented in the web mail server 56 in FIG. 7 and theclient computer 50 has only a conventional browser which accesses theweb mail service and is told what to display by said web mail service.In one multiple category embodiment, the value added process is aprocess which runs on the web mail server of an ISP like Yahoo orComcast and which transmits data downstream to the client computerbrowser to cause it to paint a display of an email inbox along the linesof FIG. 2 to call attention to the different classes of emails indifferent ways.

FIG. 7 is a block diagram of one embodiment for a system of computers inwhich some embodiments of the invention are practiced and in which theother interactions described herein occurs.

FIG. 8 is one embodiment for a software architecture in which someembodiments of the invention may be practiced.

Referring to FIG. 7, a client computer 50 is connected by some physicallayer interface 54 such as a cable modem, dial up modem, Directway modemor dial up modem, or wireless connection. The client computer typicallyhas a display, keyboard, pointing device, central processing unit,memory and a bulk storage medium of some sort is coupled to the internetbut it may be on a cell phone or something not classified as a computersuch as a PDA, Blackberry, etc. with no keyboard and possibly nopointing device). A web mail server 56 such as the Yahoo web mail serverand an email server 59 such as is operated by many ISPs are each coupledto the internet by a physical layer interface such as a cable modem, DSLmodem or TI interface. This is an example architecture only and no allelements shown are necessary in every embodiment. The same is true forserver 58 operated by the assignee of the present invention (hereafterreferred to as assignee server).

Each of the servers 58 and 56 runs application software (not shown). Theapplication software for the web mail server 56 includes a web mailapplication which gathers and stores email directed to the owners ofeach email account (referred to as an email subscriber). The webmailserver 56 stores incoming emails directed to persons having accountswith the service in such a way that each email subscriber's emails canbe retrieved by the web mail application program on demand.

This web mail application also receives requests from client computersto display the user's email and fetches the emails directed to thatuser. In some embodiments, only emails which have not already beendownloaded by the user [webmails usually don't download emails atall—email clients are the ones that download mail] are fetched fordisplay.

In one embodiment, each fetched email is then categorized into acategory to which attention will be called to the user of the webbrowser. This can be done using the source email address of the senderor the sender's ID number assigned by the assignee.

The web mail application (in embodiments where the value added processis integrated into the web mail process) then sends packets to the webbrowser of the client computer 50 to cause the web mail browser todisplay the list view of emails or whatever else was requested.

In conventional web mail applications like those executed by Yahoo,Hotmail or Comcast servers there is no bringing to attention of emailsin certain categories. However, in one embodiment, the web mailapplication program cooperates with a value added process running on theweb server to modify the display data sent to the client computer so asto call attention to emails in certain categories in different ways. Inthis embodiment, the value added process executing on the web mailserver cooperates with the web mail process also executing on the webmail server to intercept the data transmitted to the web browser of theclient computer. The intercepted data is modified prior to transmissionby the value added process such that the inbox displayed by the clientcomputer will have emails belonging to certain categories displayed incertain ways to call attention to the category they are in. In thisspecies, the categories will be displayed with logos for each categorydisplayed in distinctive locations to call attention to each email in aparticular category. In other embodiments of this subclass ofembodiments, the data transmitted by the value added process to theclient computer will cause the client computer to emit some sound orodor or other sensory output for each email in a specific category tocall attention to the emails in various categories in different ways.

In another important embodiment, the functionality of the value addedprocess just described to control the client computer to call attentionto emails in specific categories is integrated into the web mailapplication program itself. This functionality causes the web mailapplication to generate data for transmission to the client computerbrowser to cause the browser to call attention to various emails indifferent categories in different ways. Such a display could be likethat shown in FIG. 2 or any of the alternative embodiments discussed.

In addition, each server has all the other hardware and software ofinternet capable servers including: a central processing unit; a harddisk or other bulk storage to which the computer is connected bysuitable controllers such as RAID arrays; random access memory in allcases and read only memory in most cases; a network interface forcoupling the computer to the internet such as by a cable modem, DSLmodem, TI line, etc.

A sender computer 57 belonging to a branded/certified sender or whitelist sender or a phisher or other fraudulent user are each coupled tothe internet 52.

Referring to FIG. 8 one embodiment of a software architecture in whichsome embodiments operate. Operating system 64 controls the clientcomputer operations. Web browser 66 is launched by the user when a webpage is to be downloaded from the internet or searched for [the browserlaunching means the browser is started. The action to look for is whenthe URL for the webmail service is accessed]. When the web browser islaunched, it communicates with a software layer 68 via a data path 70.The data path 70 represents any method of software applicationscommunicating with and cooperating with each other. Typically, data path70 is a series of Application Protocol Interfaces (hereafter API) whichallow each software process shown in FIG. 8 to communicate with anyother software process shown in FIG. 8 by invoking function calls of theAPI of the software process with which communication is to be had. Thefunction calls allows data to be passed to the software process andinformation to be obtained from the software process.

The email client 72 functions strictly to retrieve email from whateveremail server 59 operated it is programmed to contact. When the emailclient launches, it either automatically or on command logs into anemail server such as email server 59 with the appropriate user name andpassword. The value added process 74, in the preferred embodimentcooperates with the web browser or the email client 72 and the TCP/IPlayer process 68 to control the client computer to implement the userinterface and user interface process according to this class ofembodiments.

In an important alternative embodiment, the value added process executeson a web mail server such as web mail server 56. In another importantembodiment, the functionality of the value added process is integratedinto the web mail process of the web mail server 56. In either of thesetwo alternative embodiments, the value added process functionality, beit a separate process or integrated into the web mail server process,causes the web mail server process to transmit data to client computer50 which displays the user's email and which causes certain categoriesof emails to be called to the attention of the user different throughvisual, audible or other sensor cues for each class of email. Theclasses are as previously discussed.

An exemplary process by which the value added process 74 cooperates withthe web browser 66, operating system 64 and the TC/IP process andphysical layer interface process 76 to communicate with the web mailserver 56 (or an email server) and the assignee server 58 is shown inflow diagram form in FIG. 9.

It is assumed in FIG. 9 that the value added process has already beendownloaded from the assignee server and installed on the client computer50. It is also assumed that branded senders have gone through the manualverification process and have proved their ownership of the logo,authority to use the logo and uploaded the logo they want displayed withtheir emails to the assignee server 58. The logo will be stored as animage in the assignee server 58 or elsewhere with a pointer to it storedin the assignee server 58.

The process carried out by the value added server is slightly differentdepending upon whether the recipient of email (client) is using a webbrowser like internet explorer to retrieve view his email on a webmailserver or is using an email client running on his machine to downloademails from an email server operated by the company that maintains hisor her email account. A webmail server maintains the emails on theserver itself and also composes the displays and sends the display datato the web browser on the client computer for rendering on the clientcomputer display.

In contrast, when an email client such as Thunderbird or NetscapeCommunicator executes and is asked to retrieve emails (or automaticallymakes a sweep for emails), it logs onto the email server where theuser's account is located, identifies the client and asks that emailsfor the client be downloaded to the email client. The email client thenstores them locally on the recipient computer and processes them inaccordance with which view the user wishes (inbox, sent, drafts, trash,etc.). FIG. 8 is restricted to the interaction with the web browser andwebmail server. FIG. 9 is directed to the interaction of the emailclient and the value added process.

The process of FIG. 9 also assumes that any branded/certified sender hasalready caused sender computer 57 to interact with the assignee server58 to obtain an encrypted stemp (data indicating the email has had amicropayment made for the privilege of sending it to the recipient) andhas put that stemp somewhere in the email (often in the header) and hassent the stemped email in the regular fashion. This stemped email isrouted through the internet in conventional fashion and gets stored inweb mail server 56. The process of FIG. 4 also assumes that emails sentto recipient have been digitally signed by the sender process and thatthe digital signing process involves processing of the header and bodyof the email and any other important parts that a phisher may try tospoof so as to ensure that no tampering of the email can have occurredafter the email was sent so as to allow a phisher or other unscrupulousperson to obtain any advantage from sending of the altered email.

The process of FIG. 9 starts with step 82 when a web browser on theclient computer launches. As soon as the web browser launches, it startspublishing events which can be monitored by other software applicationsto inform any application which is listening what is happening with thebrowser. Step 84 represents the process of the value added process(typically a web browser plug-in downloaded from the assignee's server)launching when the web browser launches and starting to monitor eventspublished by the web browser. The value added process may be running allthe time in some embodiments, and, in other embodiments, it launchesautomatically whenever the web browser launches as a plug-in thereto.

Whenever the web browser is directed to a web page, it publishes anevent so indicating. Step 86 represents the value added processdetecting an event that indicates the web browser has been directed tothe web mail page of a web mail server upon which the user maintains anemail account. After the user enters a username and password to log ontothe web mail server, the webmail server in step 88 sends a web pagedisplaying the contents of the user's inbox or some other box the userselects such as sent mail, drafts, trash, etc. The page displaying thecontents of the inbox is sent by the web mail server when the userselects a list view of his or her inbox.

Step 90 represents the process of the value added process detecting theevent published by the web browser indicating a page representing theinbox's contents has been sent by the web mail server. Step 90 alsorepresents the process of responding to the detection of this event bythe value added process fetching the headers of each email displayed inthe inbox from the web mail server.

Step 92 represents the value added process step of examining the headerinformation retrieved for each email and determining which emailscontain stemps. Step 94 represents the process of determining if a stempis not found in the header of the email, whether there is a flag in theheader indicating there is a stemp located somewhere else in the email.Step 94 also represents the process of retrieving the stemp from themain body of the email by doing a fetch of the main body of the emailfrom the web mail server and finding the stemp therein. Step 94 alsorepresents the process of retrieving the digital signature of any emailwhich has been digitally signed to protect it from tampering. Digitalsigning is the process of performing some sort of hashing or encryptionalgorithm on various parts of the email that it is desirable to protectfrom phishers or other people who may wish to tamper with the email.Typically, unscrupulous persons may wish to tamper with the headerand/or main body of the email to change the text therein. When theseportions of the email have been used as input to a hash or encryptionalgorithm, a result which can be decrypted or dehashed results. Thisresult is the digital signature. If an email has not been tampered with,repeating the hash or encryption algorithm on the same parts of theemail which were previously used to generate the digital signature.Retrieving of the digital signature is from the header if it is storedin the header or the web mail server if it is stored somewhere else inthe email besides the header.

Step 96 represents the process of the value added process decrypting thestemp and regenerating the digital signature using the same parts of theemail which were used to create the original digital signature. If thedigital signature only protects the header, then the retrieved header isused to regenerate the digital signature. If the main body or some otherportion of the email was used, then the value added process retrievesthe main body or whatever other part of the email which was originallyused from the web mail server and regenerates the digital signatureusing the same hash or encryption algorithm as was originally used.

Step 98 represents the process of the value added process sending to theassignee server the decrypted stemp and the regenerated digitalsignature along with an identifier of the email from which these valueswere generated along with a request to authenticate the email to verifythat it is the same email as was originally sent and has not beentampered with. Step 100 represents the value added process sending theemail address of the sender of each email in the view being displayed(or other information identifying the sender of the email) to theassignee server with a request to send back status information on eachsender.

Step 102 represents the process carried out in the assignee server ofverifying the stemp authenticity for each decrypted stemp sent to it bythe value added process. Step 102 also represents the process ofcomparing the reconstituted digital signature sent for each signed emailby the value added process to the digital signature stored for thatemail in the assignee server. If the two match, then the email has notbeen tampered with and the email is not fraudulent and information isincluded in the status information sent back to the value added processfor that email indicating that the email is not fraudulent. If the twodo not match, information is included in the status information sentback for the email indicating it is fraudulent.

Step 104 represents the process of the assignee server using the senderaddress or other information identifying the sender to look up thesender's status in a database or lookup table. Each certified or brandedsender and each white list sender is included in the database or lookuptable. The database or table also includes the member number if thesender is a registered member of the assignee's protected emailenvironment and either the trademark or other corporate identity logo ora pointer thereto for each branded sender who has passed theverification test and uploaded a logo or trademark to be displayed.

Step 106 represents the value added process using the status informationand legitimacy information sent back to it by the assignee server torequest the assignee server to download the logos of anybranded/certified senders and the logos uploaded by any white listsender. If a white list sender has not uploaded a logo, information tothat effect is included within the status information so that the valueadded process can use a generic white list logo it stores locally fordisplay with the white list sender. In some embodiments, step 106 can becombined with step 104 such that the assignee server automaticallyfetches and sends to the value added process any branded sender logo orwhite list logo it has stored for any sender identified in the requestmessage(s) from the value added process.

It is now time for the value added process to paint the display of theinbox in accordance with this class of embodiments to call attention tothe branded/certified sender emails in one way and to call attention tothe white list sender emails in another way and to call attention to thefraudulent emails in a third way. Any way in which these differentclasses of email are brought to the user's attention will suffice topractice this embodiment. Further, any way in which the value addedprocess paints the display or modifies the information received from theweb mail server to paint the display so as to call attention to thedifferent classes of email will suffice to practice this class ofembodiments. Typically, the web mail server sends back an html pagedisplaying the inbox the way the web mail server wants it displayed.This data is received by the web browser which then converts the htmlpage data into function calls and arguments which are sent to an API ofthe screen rendering process of the operating system which then controlsthe display driver to render the desired display. The value addedprocess typically utilized hooks installed by it or which are alreadypresent in the operating system rendering process or web browserrendering process to redirect the data defining the desired screen viewto a screen rendering process carried out by the value added process.This value added screen rendering process modifies the screen renderingdata to cause it to define a display such as is shown in FIG. 2 ordescribed as one of the alternative embodiments. The modified data isthen sent to the operating system screen rendering process to paint thedisplay.

Referring to FIG. 10, there is shown one embodiment of a process for thevalue added process to cooperate with an email client, an email server,the operating system to generate a display such as that shown in FIG. 2or one of its alternative embodiments.

Step 110 represents the process of the email client launching andstarting to publish events. Step 112 represents the value added processlaunching and starting to monitor events. Typically, the value addedprocess is a plug in which launches when the email client launches.

In step 114, the value added process detects an event which indicatesthe email client has logged into an email server upon which the usermaintains an email account. In step 116, after the email client logsinto the email server, the email server automatically sends to the emailclient new emails that it has been storing (or the email client requeststhem either as part of a periodic sweep or upon specific request fromthe user) in the inbox for the logged in user.

In step 118, the email client receives a command from the userrequesting it to display the contents of some box such as the inbox,trash, sent mail box, drafts, etc. The email client publishes an eventto that effect. In step 120, the value added process detects the eventindicating the desired list view and does a fetch of the header of eachemail stored in the box which the user is viewing.

Step 122 represents the value added process examining the informationretrieved from the email client regarding each email and determiningwhich email contains a stemp.

Step 124 represents a determination by the value added process as towhether a stemp is in the header of the email or elsewhere as indicatedby a flag in the header. The value added process then retrieves thestemp either from the header or fetches the main body of the email fromthe email client and fetches the stemp from the main body. The sameprocess holds for the digital signature which is retrieved by the valueadded process from the header or the main body.

Step 126 represents the value added process decrypting the stemp andreconstructing the digital signature in the same manner this was done inthe process represented by FIG. 9.

Step 128 represents the process carried out by the value added processof sending to the assignee server the decrypted stemp and thereconstructed digital signature of each signed and/or stemped email witha request for verification. Step 130 represents the process carried outby the value added process of sending to the assignee server the emailaddress of the sender of each email or other information identifying thesender. This data is sent along with the decrypted stemp and/orreconstructed digital signature of each email and includes a request forstatus of each sender. The purpose of the verification and statusrequests is to determine which emails are fraudulent and which emailsare from branded/certified senders and which are from white listsenders. All the other emails will be in a “none of the above category”.

Step 132 represents the assignee server process of verifying theauthenticity of each email for which a decrypted stemp has been receivedand/or for which a reconstructed digital signature has been received.The assignee server stores the decrypted stemp and the digital signaturecreated for each email. These values can be compared to the decryptedstemp and the reconstructed digital signature received from the valueadded process to determine if the email has been tampered with after itwas first processed by the assignee server. Any email which indicates bythese comparisons that some tampering may have occurred has a messagesent back to the value added process indicating the email is fraudulent.

Step 134 represents the process carried out by the assignee server ofusing the sender email address of each email (or other identityinformation such as the member number) to look up the status of eachsender. This look up accesses a database or look up table and determineswhich senders are white list and which are certified/branded senders.The assignee server uses the identity information to look up thelocation of any logo or trademark the branded senders have uploaded andany logo the white list senders have uploaded for display with theiremails. The identity status and legitimacy information for each email isthen sent back to the assignee server along with the location of anylogo or trademark to be displayed with each legitimate branded sender orwhite list logo. In some embodiments, the assignee server accesses thelogo or trademark image for each branded sender or white list sender andjust sends any logo or trademark image for a legitimate email to thevalue added process along with the identity status and legitimacy statusinformation for each email.

Step 136 represents the value added process using identity statusinformation and legitimacy information regarding each email to determinewhich emails need to have a logo or trademark displayed and which typeof logo or trademark to display for each. In the preferred embodiment,the value added process sends a request to the assignee server for eachemail which needs to have a displayed logo to download the logo ortrademark for each email. If the logo or trademark image is stored as aweb page on some other server other than the assignee server or on theassignee server, the value added process requests the web pagecontaining the logo or trademark directly from whatever server uponwhich it is stored.

Step 138 represents the process carried out by the value added processof modifying the data to be displayed so as to call attention to thebranded sender emails, white list emails and fraudulent emails indifferent ways. Any what this can be done will suffice. One way is forthe value added process to use hooks installed in the operating systemrendering process or the rendering process of the email client toredirect function calls and arguments directed to the operating systemrendering process to a rendering process in the value added process. Therendering process of the value added process alters the function callsand/or the arguments supplied to the operating system rendering processso as to cause a display in accordance with this class of embodiments.In alternative embodiments, the display generated by the email clientcan be used as is and commands sent to a vibration generation apparatusor a scent generating apparatus to call attention to the white list,branded sender and fraudulent emails in different ways. In the preferredembodiment, branded sender logos are displayed in the sender column andthe logos uploaded by the white list senders (or generic white listlogos if a white list sender has not uploaded a logo) are displayed tothe left of the sender column or to the right of the sender column andto the left of the subject line. Fraudulent email logos are displayed tothe left of the sender column.

Branded Mouseover Event

FIG. 11 is a screenshot of one embodiment of a user interface displaythat occurs when an event called the branded mouseover occurs. A brandedmouseover event occurs when a user passes his or her mouse over an emailfrom a branded sender which is displayed in the chosen list view such asthe inbox with an associated graphic. The idea is to display a pop upbox which has more information about the branded sender. In the exampleshown in FIG. 11, a pop up box giving more information about brandedsender Citibank—is displayed. This pop up box displays information aboutCitibank such as that Citibank is a Verified Truemark Sender, theirlogo, the license agreement version between the assignee and Citibank,the verify date when the assignee performed the due diligence checks tomake sure Citibank had the right to display the logo and the person whosigned the license agreement with the assignee had the authority to bindthe company and a certification that Citibank is a certified/verifiedsender of the and abides by the same framework outlined by the U.S.Department of Commerce and the European Union. In the preferredembodiment, this pop up box appear each time the mouse passes over abranded sender email where the send has an associated graphic. In otherembodiments, a menu choice to turn this feature on or off is presentedsince the constant popping up of pop up boxes might annoy the user ifthe user knows that the email would not appear in the inbox and set offas being from a branded sender unless it had been verified as being froma branded sender.

The process to implement branded mouseover has the value added processmonitoring events published by the operating system as to the positionof the mouse and comparing the position to the positions of displays ofthe various emails. When the mouse is over a position occupied by abranded email, the value added process retrieves the pop up block imagefor that branded sender either from local storage or the assignee serverand sends commands to the operating system rendering process API todisplay the pop up box.

In some embodiments, branded sender emails are put into a user's inboxdisplay without checking their authenticity, and the user causes such anauthenticity check to be performed by doing a mouse over. When the userplaces her mouse over a branded email, the value added process detectsthis fact and sends an inquiry to the assignee server and passing to itthe identity of the sender of the branded email. The assignee serverthen looks up the status of the sender of the allegedly branded email,and if the sender is a branded email sender, the assignee server sendsback verification of this fact along with the data for the pop up boxshown in FIG. 11. The value added process then makes appropriate callsto the OS rendering process API to render the pop up box over thecurrent list display.

White List Mouseover Display

FIG. 12 is a screen shot showing a layered buddy mouseover pop-updisplay which occurs when a user passes the mouse cursor over a whitelist email currently being displayed. In embodiments where white listemails do not get to the point of being displayed in a list view untilthey have been authenticated, the white list mouseover process works asfollows. When the user passes the mouse cursor over a email sent fromsomebody on the white list, the value added process detects this eventand determines which white list sender's email currently has the cursorlocated over it. It then looks up the data for a pop-up box, and makesappropriate function calls to the OS rendering system API to display thepopup box for that particular white list sender. Typical data displayedare the gender and birthday of the buddy (white list senders may not allbe buddies—some may be clients or business associates), the location andoccupation of the buddy, the interests, favorite party drinks, songs orsong genres the buddy likes, the favorite restaurants or local hang outsthe buddy favors and what person or thing the buddy is a secret fan of,links to blogs, photo album links, instant messenger status, etc.

In some embodiments, where all emails get displayed before they areauthenticated, the buddy mouseover process works as follows. When themouse cursor is placed over an email from a white list sender, the valueadded process detects this event and compares the cursor location to thelocations of display of the emails currently being displayed so as todetermine which email has the mouse cursor located over it. The valueadded process then fetches the header data for this email and determinesthe identity of the sender either from the sender's email address orfrom member number metadata received from the assignee server. Theidentity of the sender along with other information needed toauthenticate the email such as a reconstructed digital signature is thensent to the assignee sewer with a request to authenticate the email tomake sure it is actually from the white list sender it purports to befrom. The assignee server then authenticates the email in any way,typically by comparing the reconstructed digital signature to theoriginal digital signature created when the email was sent. If the emailappears to be authentic, the assignee server sends back the data neededfor the popup box. The value added process then renders the popup boxusing the data received from the assignee server.

Affinity Display

In some embodiments, it is useful to have a visual cue on the display ofemails which gives an immediate indication to the user regarding thestrength of the relationship with a particular email sender. FIG. 2shows one species of this subclass of embodiments with an affinitydisplay shown at 150 as a grouping of stars or asterisks. Any symbolcould be used. The idea is that the number of symbols in the group is anindication of the strength of the relationship with that sender. Thevisual indicator could also be a distinctive color with severaldifferent colors being used to represent several different levels ofstrength of relationship.

In the embodiments represented by FIG. 2, the number of stars present at150 is based upon the number of email interactions had with the sender.The number of email interactions is stored and retrieved from a serverwhich can be the same server used to store sender information (useassignee server). In other embodiments, the recipient may enter data ina configuration file in the assignee server which manually establishesthe strength of the relationship with each member of the recipient'swhite list.

Embodiments Using Third Party Authentication Services

Referring to FIG. 13, there is shown an overview process flow diagramshowing one class of embodiments of how emails are authenticated andcategorized and displayed with Truemark pay-for-play branding or whitelist icons or fraud icons. Block 152 represents a browser process oremail client process running on a computer at a branded sender such asCitibank. A user composes an email addressed to the user of computer154. This mail is sent by regular channels, as symbolized by line 156and is routed to the recipient computer 154 which receives it either byusing a browser process or an email client in the manner describedpreviously, a process represented by block 158.

Block 160 represents a process of checking the received email for domainauthenticity and integrity. No logo display by the value added processnor any other process by the value added process running in recipientcomputer 154 will be carried out to call attention to an email in aparticular category until the email has been authenticated.

In carrying out this authentication process, any known process to checkto verify the domain the email came from is the domain the emailpurports to have come from will suffice, and that is the meaning ofdomain authenticity. Further, any known process to check the integrityof the email to ensure it has not been tampered with will suffice, andthat is the meaning of integrity. One example of how both domainauthenticity and integrity can be checked is through use of anyimplementation that complies with the Domain Keys specification patentedby Yahoo. Other examples of technologies that can be used to checkdomain authenticity and/or integrity are: the techniques available fromMessage Level, Inc. (special token created on a server when an emailsent and with email received, the token is retrieved, its presenceindicating the email is valid; those technologies taught in U.S. patentapplication entitled METHOD AND APPARATUS FOR IMPLEMENTING AMICROPAYMENT SYSTEM TO CONTROL E-MAIL SPAM, filed Feb. 12, 2004 andhaving Ser. No. 10/778,956, which is hereby incorporated by reference;SPFiSender ID (a technology AOL tried to implement involving publishingan anti-spam policy about who can send mail on behalf of the companyusually listing a specific IP address or range of addresses, and thereceiver of the mail verifies the sender using the policy); S/MIME(email is encapsulated in an envelope, and the contents of the envelopeis encrypted with a private key of a public key-private key pair—thesender's public key is used to decrypt the envelope contents) andcryptographic techniques (the message is encrypted with the private keyof the sender, and the recipient looks up the public key of the senderand uses it to decrypt the message).

After the domain authenticity and integrity of the message have beenchecked, a value added process cooperating with a web browser process oremail client process executing in computer 154 obtains the informationin the sender field of the header of each email and sends thatinformation to a server run by the assignee, represented by block 162.The process of sending the sender field contents to server 162 with arequest to look up the “reputation” of the sender is represented by line164. The reputation of the sender is at least what category is thesender in: branded; white list; fraudulent; or other. In someembodiments, another category is present which is a person who is asubscriber to the assignee's services but who is not on a white list ofthe recipient, not fraudulent and not a branded sender. The assigneeserver 162 uses the sender's identification information to look up thecategory of the sender and sends back that information to clientcomputer 154.

Finally, the client computer value added process uses that reputationinformation and the information developed during the domain authenticityand integrity check to change the function calls and arguments made bythe email client process or the web browser process to the operatingsystem of computer 154 to cause any of the displays or other methodsdescribed above of calling attention to emails of different categoriesin different ways, as represented by block 166. If an email is authenticand from a branded sender, the preferred embodiment displays theTruemark of the sender in the sender column. The Truemarks and whitelist logos and fraud logos may be stored in computer 154 or fetched fromassignee server 162 using location information supplied by server 162with the reply to the reputation lookup request 164.

FIG. 14 is a protocol flow diagram of one embodiment of a processimplemented by uniquely programmed computers to do the authenticationprocess mentioned above in the description of the protocol and flow ofcommunications represented by FIG. 13. A client computer 152 on thenetwork (or stand alone) originates an email and sends it (169) to theoutgoing mail server 170 of the branded sender (if they have their ownemail servers) or of an ISP with whom the sender has an account in thecase of either a branded sender or a white list sender. All brandedsenders will have to have a Domain Keys implementation running on theiroutgoing mail server 170 in order to digitally sign outgoing emails. Thedomain keys implementation can be anything, and free copies areavailable for download. All domain keys implementations must comply withthe Domain Keys specification. The server 170 signs the mail with aprivate encryption key of MUA 152 from a private key, public keyencryption key pair.

A digital signature is prepared (172) to protect the parts of the emailto be protected from tampering using the private key of MUA 152. Tocompute the digital signature, the main body of the email, anyattachments and anything else that needs to be protected from tampering(such as the header) is hashed. That hash value is then encrypted withthe private key of the domain from which the email originated togenerate a digital signature. That digital signature is then put into aspecial header in the email.

The digitally signed email is then sent (174) over the internet 176 andgets routed to the incoming mail server 178 of the recipient. The emailwhich is sent has the body of the email and the header sent in the clearbut includes the digital signature in the authentication header.

The incoming mail server 178 sends the email to the recipient's clientcomputer 180 when an email client (not shown) process on client computer180 requests download of the recipient's emails. Alternatively, server178 is a Web mail server and, when a web browser process (not shown) onthe client computer 180 logs in and requests display of the recipient'semails, the server 178 sends data to client 180 which causes the clientto display an email inbox and a list view of the emails that have notbeen previously downloaded. When the user clicks on an email, a requestis sent to server 178 to send data that causes client computer 180 todisplay the contents of the email, and that data is then sent. A valueadded process running in the client computer then fetches the main body,header and digital signature of each signed email.

The client computer must then authenticate the email. To do this, theclient computer 180 sends a request to a DNS server 182 of the sender.This request is for the public key of the sender. The DNS server repliesby sending the public key back to the client computer. The clientcomputer 180 then computes the same hash value from the same parts ofthe email and using the same hash algorithm that was used when thedigital signature was originally prepared. The client computer thendecrypts the digital signature from the email header with the public keyto recover the original hash value and compares the two hash values. Ifthe hash values match, the email has not been tampered with. If the hashvalues do not match, the client computer determines that the email hasbeen tampered with.

Because the public key comes from the domain name server of the senderthe email purports to be from, if the public key does not match thepublic key in the public-private key pair of the sender, then it meansthe email did not originate in that domain and is a spoof or otherwisefraudulent. Also, if the digital signature does not decrypt properly,the email has been tampered with.

The client computer then proceeds to a reputation lookup as previouslydescribed in connection with the discussion of FIG. 13.

FIG. 15 is a flow diagram of another way of doing the authenticationstep. The embodiment represented by the process flow of FIG. 15 differsfrom the embodiment represented by the process flow of FIG. 14 in thatthe digital signature verification is done in server 178 instead ofclient computer 180. In some embodiments of this species, the web mailserver 178 will not even display an email in a list of a recipient'semails unless the email has been authenticated. In other embodiments,the list of emails will be displayed to a web browser running on clientcomputer 180 and the headers thereof can be fetched by the value addedprocess running in computer 180, but until the email is authenticated,no data is added to its header indicating the mail is authenticated.Until such data is added to an email header, the value added processrunning in client computer 180 will treat it as outlaw email and willnot display any Truemark or white list logo. In some species, the valueadded process will not display the email at all until some data is foundin the authentication header indicating the email is or is notauthentic. Appropriate action regarding checking the category status ofthe email is then taken to determine how to display it.

In the process of FIG. 15, the originator computer creates and sends theemail to outgoing mail server 170 which signs it with a private key andsends it over the internet to an incoming mail server 178 (or web mailserver). The email is sent with the body, header and any attachments inthe clear with the digital signature in the authentication header.

To authenticate the email, the hash which was used to create the digitalsignature is re-created in the incoming mail server 178 in the same wayas described with respect to the embodiment of FIG. 14 (the body andattachments are hashed using the same hash algorithm as was used tocreate the hash which was input to the digital signature process). Toauthenticate the email, the incoming mail server 178 then makes arequest 179 to DNS server 182 in the domain of the sender for the publickey that corresponds to the sender identity of the email received. TheDNS server sends back the public key, and the server 178 then uses thepublic key to decrypt the digital signature in the email'sauthentication header to recover the original hash and compares the twohash values to verify integrity and domain authenticity. If the digitalsignature does not decrypt properly, there is a mismatch in theprivate-public key pair and the email probably did not originate fromthe domain of the domain name server 182. The email is then sent to theclient computer 180 with information inserted in a new header called anauthentication results, said information indicating whether the emailpassed authentication or not (181).

The client computer 180 has a value added plug in process running on it.This value added process fetches the header and authentication resultsheader of each email. It then performs the reputation lookup processpreviously described for all emails which are authentic by sending thesender identity (contents of the sender field in the header) to a serveroperated by the assignee. Status information is then looked up by theassignee server, and sent back to the client computer value addedprocess with a pointer to any Truemark logo or white list logoassociated with any email in the branded sender or white list category.This lookup uses the sender identity to first determine if the sender isa branded sender. If not, then the recipient identity (which is alsosent by the client computer 180 with the request) is used to look up thebuddy list of this recipient and determine if the sender is on thatbuddy list. The value added process then uses this status informationreceived back from the assignee server to control the client computer tocall attention to the various categories of emails in any of thedifferent predetermined ways previously discussed. In some embodiments,there is another category of sender which are not branded senders, notwhite list buddies, but they are members with subscriptions to theservice provided by the assignee.

FIG. 16 is a table that shows what is displayed for each differentauthentication result for each different category in embodiments wherethere are five categories: Truemark customer with FUAP set to true;Truemark customer with FUAP set to false; white list buddy; non memberbuddy; and non member.

The first line in FIG. 16, shown at 200 indicates what will be displayedin a display such as that shown in FIG. 2 for three differentauthentication test results when the FUAP option is set to true. If anemail originates from the Truemark customer's domain, and it passes theauthentication tests described above, this case will be referred as theTruemark case. In the Truemark case, the Truemark logo or registeredtrademark of the customer will be displayed in the sender column 10 ofFIG. 2. This logo or registered trademark will be displayed in thesender column if and only if the sender proves the right to use the markto the assignee of the invention during the due diligence processcarried out when each Truemark customer first subscribes to theprotected email space service. If an email originates from a Truemarkcustomer's domain, but this email does not pass the authentication testor the authentication test has not been performed, then the fraud icon42 will be displayed in the sender column or next to the sender columnwith the identity of the sender grayed out with a strikethrough fontdisplayed or the word “phishing” displayed in a grayed out,strikethrough font such as is shown at 42 in FIG. 2.

Line 202 of FIG. 16 indicates what will be displayed for variousauthentication results for a Truemark customer with its FUAP option setto false. If an email originates from the customer's domain and itpasses the authentication test, the customer's Truemark will bedisplayed. If the email fails the authentication test or theauthentication test has not been performed, then nothing will bedisplayed meaning the email will not be displayed at all in someembodiments or the email subject line will be displayed, but nothingwill be displayed in the sender column for that email.

If the sender is a white list buddy, line 204 indicates that thesender's buddy icon or a generic white list icon will be displayed nextto the sender column or in the sender column regardless if the emailpasses, fails of is not tested by the authentication process.

Line 206 signifies that if the sender is a non member buddy, the genericnon buddy icon will be displayed next to or in the sender column forthat email.

Finally, line 208 signifies that if an email is from a non member,nothing will be displayed (no special logos or other calling attentiontechniques employed) for this email and it will be displayed just likeany regular email was displayed before this invention.

FIG. 17 is a flowchart of the preferred embodiment of a process fordisplaying external personalized sender data with a received email. Step210 represents the process of the assignee server storing personalizeddata for a sender such as the data displayed in the mouse over examplepreviously discussed. This happens when a member subscribes to theservice so he or she can upload a buddy icon for storage in the assigneeserver.

Step 212 represents the sender sending an email to a recipient. In step214, the recipient receives the email. In step 216, the recipient's MUAclient system requests from the assignee server the sender'spersonalized data. The assignee server receives the request and appliesany relevant policies applying to data access in steps 218 and 220. Therecipient's MUA system receives the sender's personalized data from theassignee server in step 222, and displays it in association with thesender's email in step 224. This can be, for example, by displaying thepersonalized sender data in a pop up window when the mouse is passedover the email from that sender displayed in the email list view.

FIG. 18 is a flowchart of the preferred process of presenting anunsubscribe interface. This ability to unsubscribe is required byfederal law. Step 226 represents the process of the sender creating anunsubscribe web service. In step 228, the unsubscribe service link isstored as sender data on the assignee server system. In step 230, thesender sends an email to a recipient, and in step 232, the recipientreceives the email. In step 234, the client system requests the sender'sdata which was stored in step 228 from the assignee server. The assigneeserver receives this request in step 236 and returns the sender data instep 238. The returned data includes the unsubscribe web service link.In step 240, the recipient's MUA client system receives the senderunsubscribe link. In step 242, the client MUA displays a button inassociation with the email for unsubscribing to sender emails. If therecipient “presses the button”, the unsubscribe link is invoked and therecipient is removed from the sender's email list.

FIG. 19 is a flowchart of a process for presenting frequency metricswhich are used by the recipient MUA to create distinctive displays foremails, said displays indicating the amount of communication that hashistorically been had with the sender of an email to which the frequencymetrics apply. Step 244 represents the process of an email clientsending a tuple contain the sender and receiver of an email to theassignee server whenever an email is sent or received. In step 245, theassignee server updates a count pertaining to the particular sender andreceiver identified in the received tuple. Separate counts aremaintained in the assignee server for each sender and recipient of whichit has been informed. Step 246 represents the process of sending theemail to the recipient from the sender MUA. In step 248, the recipientMUA receives the email. In step 250, the recipient MUA sends a messageto the assignee server requesting a count of the number of emails thathave been sent between the sender and receiver of the email justreceived. In step 252, the assignee server receives this request, and instep 254, the assignee server returns the requested count. In step 256,the client system receives the count data from the assignee server, and,in step 258, the client MUA process displays the email with a number ofstars near the sender identification field, the number of stars beingindicative of the number of emails that have passed between the senderand receiver historically. See FIG. 2 step 150 for an example display ofa metric for frequency of communication.

FIG. 20 is a flowchart of the preferred embodiment process for detectingfraudulent emails and displaying them with a fraud indication. Step 260represents the process of a legitimate sender storing a policy fordetecting emails that are fraudulent on the assignee server. Such apolicy typically is that all email which has not passed anauthentication and integrity check must be presented as fraudulent. Step262 represents the process of a phisher or other fraudulent sender(hereafter the phisher) sending an email claiming to be from thelegitimate sender which established the policy in step 260. In such acase, the phisher's mail transfer agent process forwards the email butdoes not digitally sign the email, as represented by step 264. Step 266represents the process of the recipient's mail transfer agent checkingfor a digital signature (which all legitimate emails from the legitimatesender will have) in the received email and not finding one. Step 268represents the process of adding an authentication header to the emailhaving data indicating that authentication failed. Step 270 representsthe process of the receiver receiving the email that failedauthentication. Step 272 represents the process of the recipient MUAclient system making a request for sender data to the assignee server.In step 274, the assignee server system receives the request, and in276, the assignee server returns the sender data including the fraudpolicy. In step 278, the client system receives the fraud policy sentfrom the assignee server. In step 280, the teceipient MUA client systemlooks at the authentication header of the received email and notes itfailed authentication. It then looks at the fraud policy of the senderand determines that the email should be displayed with a fraudindication next to it. The recipient MUA client computer then displaysthe email with a fraud logo next to the sender column or in any otherway indicates the email is fraudulent.

Referring to FIG. 21, there is shown a flow diagram of a process carriedout by a value added process to authenticate and integrity checkincoming emails and display Truemarks. In step 282, a web browserlaunches and starts publishing events. In step 284, the value addedprocess launches and starts monitoring events. The value added processdetects an event indicating the web browser has been directed to awebmail page on which the user has an email account. In step 288, theuser logs onto the webmail service, and the webmail server sends to theuser's MUA a page displaying the user's inbox (or whatever other viewthe user requests such as sent, trash, etc.). In step 290, the userdetects this event and fetches the header of each email displayed fromthe webmail server. The value added process then makes a web servicecall to retrieve the Truemark of the sender (if available) for eachsender's email address in the inbox. This call is typically made to theassignee server, but the Truemarks may be stored elsewhere and therecipient MUA knows where they are stored from previous communications.For any emails for which the sender has a Truemark, an authenticationcheck is made to ensure the email in fact came from that sender, and anintegrity check is made to verify that the email has not been alteredfrom its original state. For example, if the sender publishes a domainkeys record, then a domain keys validation is performed in accordancewith the domain keys specification. In step 296, the emails which havepassed the authentication and integrity checks are deteremined from datain an authentication header added by the authentication and integritychecking process. In step 298, the recipient MUA client system requestthe fraud policy of the sender from the assignee server and receives it.Finally, in step 300, the fraud policy is examined and theauthentication header of each email from the sender whose fraud policywas downloaded is examined. For those emails which passed theauthentication and integrity checks and who satisfy the fraud policy, aTruemark is displayed.

Although the invention has been disclosed in terms of the preferred andalternative embodiments disclosed herein, those skilled in the art willappreciate that modifications and improvements may be made withoutdeparting from the scope of the invention. All such modifications areintended to be included within the scope of the claims appended hereto.

1. A method, including: detecting a message within a browser;identifying a sender of the message; and acquiring personalized dataassociated with the sender from an external service and associating thepersonalized data with the message within the browser.
 2. The method ofclaim 1 further including: acquiring a distinctive graphic to identifythe sender; and presenting the distinctive graphic in connection withthe message within the browser.
 3. The method of claim 2 furtherincluding, presenting at least a portion of the personalized data if thedistinctive graphic is selected or if the distinctive graphic is boughtinto focus by a selection device within the browser.
 4. The method ofclaim 1 further including, presenting at least a portion of thepersonalized data within a first view associated with the message orpresenting the portion of the personalized data within a second viewthat is separate and distinct from the first view.
 5. The method ofclaim 1 further including, playing a distinctive sound on a deviceassociated with the browser in response to identifying the sender. 6.The method of claim 1 further including, distinctively identifying thesender within a display header associated with the message within thebrowser, wherein the distinctive identification includes a link toacquire the personalized data associated with the sender.
 7. The methodof claim 1 further including, attaching the personalized data to themessage as an attachment which when open presents the personalized data.8. A machine-accessible medium having instructions residing therein, theinstructions when accessed by a machine perform a method, including:receiving an identifier for a sender from a browser service; acquiringpersonalized data for the sender; and supplying the personalized data tothe browser service for access within a browser in connection with amessage received from the sender.
 9. The medium of claim 8 furtherincluding instructions for registering the personalized data from thesender prior to receiving the identifier for the sender from the browserservice.
 10. The medium of claim 8 further including instructions forsupplying a distinctive graphic with the personalized data to thebrowser service, wherein the browser service presents the distinctivegraphic with the message or with a header of the message to identify thesender.
 11. The medium of claim 10 further including instructions forlinking the distinctive graphic to the personalized data for the browserservice.
 12. The medium of claim 8 further including instructions forassigning different access permissions for different portions of thepersonalized data in response to an identity associated with the browserservice or with a user of the browser service.
 13. The medium of claim12 further including instructions for encrypting some portions of thesupplied personalized data for which the browser service or for whichthe user is not authorized to view pursuant to a particular one of theaccess permissions.
 14. The medium of claim 8, wherein receiving furtherincludes receiving an email address for the sender as the identifierfrom the browser service.
 15. A system, including: a personalizedinformation service; and a browser service, wherein the browser serviceis to process messages received from a message service within a browserand is to further send identifiers of senders of those messages to thepersonalized information service, and wherein the personalizedinformation service is to acquire personalized information for thesenders and supply the personalized information back to the browserservice for processing in connection with the messages within thebrowser.
 16. The system of claim 15, wherein the personalizedinformation service is to further interact with the senders to receiveand record the personalized information.
 17. The system of claim 15,wherein the browser service is to present selective portions of thepersonalized information within the browser in connection with themessages.
 18. The system of claim 15, wherein the browser service is toautomatically present the personalized information within the browser inconnection with the messages.
 19. The system of claim 15, wherein thebrowser service is to present the personalized information within thebrowser in connection with the messages in response to one or moreactions taken by a user within the browser with respect to the messages.20. The system of claim 15, wherein the personalized informationincludes distinctive graphics that the browser service is to present inconnection with presentations of the messages within the browser, andwherein each distinctive graphic identifies a particular one of thesenders.